%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\documentclass{l3deliverable}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\usepackage{svn-multi}
\svnid{$Id: d2.tex 47 2011-11-29 11:35:57Z 0906578c $}
\version{SVN Revision \svnrev~ \

Made \svnday/\svnmonth/\svnyear~ by \svnauthor}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% a utility environment for formatting tasks - see document for usage
\usepackage{tabulary}
\newenvironment{PSDTask}[2]{
  \tabularx{\linewidth}{|l|X|} \hline
    \bf\itshape Task #1: & \bf\itshape #2 \\\hline
}{\endtabularx}

\newcommand{\PSDTaskComponent}[2]{\it #1: & #2 \\ \hline}
\newcommand{\PSDTaskDescription}[1]{\PSDTaskComponent{Description}{#1}}
\newcommand{\PSDTaskOutcomes}[1]{\PSDTaskComponent{Outcomes}{#1}}
\newcommand{\PSDTaskDeliverables}[1]{\PSDTaskComponent{Deliverables}{#1}}
\newcommand{\PSDTaskRisks}[1]{\PSDTaskComponent{Risk}{#1}}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\usepackage{url}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%% Check these macro values for appropriateness for your own document.

\title{Project Plan}

%%authors
\author{
  David Newall \\
  Daniel Callander \\
  Stephen McQuistin \\
  Ian Scott \\
  Agnieszka Kielbinska}

%%release date
\date{12 October 2011}

\deliverableID{D2}
\project{PSD Group Exercise 1}
\team{'Special' K}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\begin{document}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\maketitle

\tableofcontents

\newpage

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%% Standard section for all documents

\section{Introduction}

\subsection{Identification}

This is project plan of the electronic voting system for Team Special K.

\subsection{Related Documentation}

PSD3 Group Exercise Description
http://fims.moodle.gla.ac.uk/file.php/128/assessment/ge-1.pdf

\subsection{Purpose and Description of Document}

The purpose of this document is to plan the execution of the project,
it will include all the tasks necessary to successfully complete
it. Specifically, the document includes;\newline
\begin{itemize}
\item{A work breakdown structure, which will identify tasks to be
  completed, give a short description and mention any outcomes or
  deliverables that will be produced.}
\item{The allocation of resources, mainly work hours, as well as a
  schedule for completion.}
\item{An assurance plan, outlining activities for the assurance of the
  software and any other deliverables.}
\item{A risk management plan to identify any risks affecting
  development and a configuration management plan.}
\end{itemize}

\subsection{Document Status and Schedule}

This is the final version of this document. A week has been spent correcting errors in the draft, then Section 3 titled Assurance Plan and section 5, Configuration Management Plan were added the following week. This version is to be submitted as part of Deliverable 4, due on the 1st of December.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\section{Resources, Budgets, Schedules and Organisation}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\subsection{Work Breakdown Structure}

We have broken the project down into a number of discrete tasks and milestones. Milestones have been based off of the deliverable hand-ins, as they match well with the rest of the project tasks. Following is the list of tasks to be done, with their description, outcomes, deliverables and risks, as well as the milestones and their descriptions. The specifics of tasks beyond Task 6 (Summarize all current documentation) are unknown to us and are thus provisional.

\subsubsection{Elicitation}
\begin{PSDTask}{1}{Create use case diagrams}
  \PSDTaskDescription{The purpose of this task will be to identify actors and functional requirements from the initial problem definition and then to create use cases for them.}%
  \PSDTaskOutcomes{Use case diagrams.}%
  \PSDTaskDeliverables{D3 - Requirements Specification Document}%
  \PSDTaskRisks{The problem definition may be misunderstood which can lead to inappropriate assumptions and incorrect use case diagrams.}
\end{PSDTask}
\newline
\newline
\newline
\begin{PSDTask}{2}{Prepare for stakeholders interview.}
  \PSDTaskDescription{The aim of this task will be to prepare a set of questions which may help to clarify the requirements of the software, and to guide us through the interview. The group must also be prepared to help the client decide what is it that they really need.}%
  \PSDTaskOutcomes{Interview plan.}%
  \PSDTaskDeliverables{None.}%
  \PSDTaskRisks{Questions may not be relevant.}
\end{PSDTask}
\newline
\newline
\newline
\begin{PSDTask}{3}{Interview stakeholders about the system.}
  \PSDTaskDescription{The intention of the interview will be to recognize the client's needs and to draw up a more detailed specification of the problem. To determine as many functional and non-functional requirements as possible.}%
  \PSDTaskOutcomes{Draft specification document.}%
  \PSDTaskDeliverables{None.}%
  \PSDTaskRisks{The client's thoughts may be unclear and answers too vague.}
\end{PSDTask}
\newline
\subsubsection{Specification}
\begin{PSDTask}{4}{Write requirements specification}
  \PSDTaskDescription{The purpose of this task will be to summarize all information gathered about the system so far, and to produce a formal description of the requirements.}%
  \PSDTaskOutcomes{Requirements Specification Document.}%
  \PSDTaskDeliverables{D3 - Requirements Specification Document.}%
  \PSDTaskRisks{Some requirements may be misunderstood, or still unclear.}
\end{PSDTask}
\newline
\newline
\newline
\begin{PSDTask}{5}{Create prototype}
  \PSDTaskDescription{The aim of this task will be to brainstorm ideas for possible design and implementation solutions.}%
  \PSDTaskOutcomes{Design prototype.}%
  \PSDTaskDeliverables{None.}%
  \PSDTaskRisks{Group may vary ideas which may cause arguments and delays.}
\end{PSDTask}
\newline
\newline
\newline
\begin{PSDTask}{6}{Summarize all current documentation}
  \PSDTaskDescription{The purpose of this task will be to gather all the documentation produced so far and summarize this into one document.}%
  \PSDTaskOutcomes{Documentation summary.}%
  \PSDTaskDeliverables{D4 - Final Report.}%
  \PSDTaskRisks{Information contained in previous documents may be inconsistent.}
\end{PSDTask}
\newline
\newline
\newline
\begin{PSDTask}{7}{Create draft design of the system}
  \PSDTaskDescription{The aim of this task is to decide on the appropriate framework from which the system can evolve.}%
  \PSDTaskOutcomes{Initial design.}%
  \PSDTaskDeliverables{None.}%
  \PSDTaskRisks{Incorrect techniques may be used, which will lead to inefficiencies within the system.}
\end{PSDTask}
\newline
\newline
\newline
\begin{PSDTask}{8}{Create design document}
  \PSDTaskDescription{The purpose of this task will be to create a formal description of the system design. It will also contain the rationale behind each design technique used.}%
  \PSDTaskOutcomes{Design document.}%
  \PSDTaskDeliverables{D5 - Design document.}%
  \PSDTaskRisks{Not all design techniques have been described.}
\end{PSDTask}
\newline
\subsubsection{Implementation}
\begin{PSDTask}{9}{Implement the system}
  \PSDTaskDescription{The aim of this task is to implement the entire system using techniques described in the design document, based on the requirements specified.}%
  \PSDTaskOutcomes{Fully implemented system.}%
  \PSDTaskDeliverables{None.}%
  \PSDTaskRisks{Time delay within the project. System may not be fully functional.}
\end{PSDTask}
\newline
\subsubsection{Validation}
\begin{PSDTask}{10}{Test plan}
  \PSDTaskDescription{This task will focus on creating a test plan which will then be employed to fully test the system for any potential errors or ambiguities within the system.}%
  \PSDTaskOutcomes{Test plan.}%
  \PSDTaskDeliverables{D6 - Test plan.}%
  \PSDTaskRisks{The test plan may not be comprehensive enough to detect every error in our implemented system.}
\end{PSDTask}
\newline
\newline
\begin{PSDTask}{11}{Test and evaluate system.}
  \PSDTaskDescription{The purpose of this task is to carry out the test plan, testing and evaluating our implemented system compared to the project requirements.}%
  \PSDTaskOutcomes{System should meet requirements and should satisfy the client's expectations.}%
  \PSDTaskDeliverables{D8 - Final report and system demonstration.}%
  \PSDTaskRisks{There may not be enough time to carry out this task fully, causing us to potentially miss some catastrophic bugs in the system.}
\end{PSDTask}
\newline
\newline
\newline
\begin{PSDTask}{12}{Final summary and presentation}
  \PSDTaskDescription{The aim of this task will be to write a report on the whole project, describing what has been done, why it has been done, what problems have been encountered and how were they dealt with. A short presentation will also be given to summarize the project.}%
  \PSDTaskOutcomes{Report and presentation.}%
  \PSDTaskDeliverables{D8 - Final report and system demonstrations.}%
  \PSDTaskRisks{Stakeholder will feel that the implementation does not fully reflect their vision of the system.}
\end{PSDTask}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\subsection{Resource Estimation and Allocation to WBS\label{sec:allocation}}


As we have decided to allocate roles and tasks as we come to them, no explicit resource allocation has been defined. Many tasks will also be completed as a full group activity rather than individually assigned tasks. The project spans over \textbf{twenty four weeks} from the beginning of term, thus we have that much time to allocate. The \textit{Schedules} section below goes more into detail about the effort required and duration set for each task.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\subsection{Schedules}

Following is a task table representing the tasks in the project, their dependencies, the estimated effort to complete that task, and the duration allocated to complete that task, both in work hours. 
We will split the work up evenly so each persons estimated effort and allocated time should be about a fifth of these figures. 
\begin{table}[h]
\begin{center}
\begin{tabular}{| c | c | c | c |}
\hline
Task & Estimated Effort (hours) & Time Allocated (hours) & Dependencies \\
\hline
T1 & 5 & 10 &  \\
\hline
T2 & 10 & 20 & T1 \\
\hline
T3 & 5 & 10 & T2, T1 \\
\hline
T4 & 5 & 10 & T3 \\
\hline
T5 & 15 & 30 & T4 \\
\hline
T6 & 10 & 20 & T5 \\
\hline
T7 & 5 & 10 & T4, T5 \\
\hline
T8 & 10 & 20 & T7 \\
\hline
T9 & 30 & 60 & T8 \\
\hline
T10 & 10 & 20 &  \\
\hline
T11 & 10 & 20 & T9, T10 \\
\hline
T12 & 30 & 60 & T6, T8, T9, T10 \\
\hline
\end{tabular}
\caption{Outline of task durations and dependencies}
\end{center}
\end{table}

This information has also been detailed in a Gantt chart, and a dependency graph, shown below.

\begin{figure}
\centering
\includegraphics[scale=0.7, angle=90]{img/gantt.png}
\caption{Gantt chart}
\end{figure}

\begin{figure}
\centering
\includegraphics[scale=0.7]{img/depgraph.png}
\caption{Dependency graph}
\end{figure}


Each task duration is given in hours as in the table below. However, in the Gantt chart this is represented over days as this reflects our schedule more accurately considering that we are not only working on this project alone and our time is split over several projects.

In the dependency graph the hours on the left hand side of the nodes correspond to the minimal amount of time needed to complete that specific task. 
The hours on the right hand side of the nodes correspond to the maximum amount of time that can be spent on that specific task. 

\newpage
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\subsection{Equipment, Materials, Facilities, and Other Resources}

All equipment, facilities and materials required to complete this project, i.e: computers, space for group discussion, text describing the basic idea of the project, and so on is provided by the University. \textit{Software Engineering (9th Ed., Sommerville)} is also available for use to understand how to plan and schedule the project.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\newpage
\section{Assurance Plan}

In our team the Quality Assurance is performed by the entire group for both software and any other deliverables. 
Sometimes we work on the deliverables (documents and/or code) together and in that case all team members should agree on the content and the style of the final document by carrying out the immediate quality assurance. 
\newline
\newline
However when working on deliverables individually we tend to split the tasks clearly so that each person is responsible for different section of the particular document or code. In this case the Quality Assurance process is as follows:

\subsection{Review and acceptance testing of products}
Whenever a person has finished working on their section of a document or code, after committing appropriate files to the SVN repository they should email all team members in order to let the rest of the team to review and hopefully accept their work.
Whenever a team member receives this email notifying them that new files have been commited to the repository they must review such files for any spelling or grammar errors as well as for style and correctness and either agree on the content of those files and accept their state or inform the author of those files of any changes that should be made. 
Minor issues about changes to files should be resolved between the review and the author. However, in cases where the issue cannot be resolved easily it should be brought up during a team meeting and solved through a team discussion.
\subsection{Verification and validation procedures}
Before a deliverable needs to be handed in we do a peer-review of all documents and code to be handed in. We go over each file in turn and proof read it, check for spelling or grammar mistakes as well as rationality and logic. As for the software we also check for the quality and correctness of the code. 
By this point everyone should have finished their other tasks so everyone should be able to act as Quality Assurer.
\newline
\newline
Due to the laissez-faire structure of our team, which results in no designated team leader, the verification and validation procedures are always performed by the entire team  and as a result the team as a whole is always responsible for the final approval of software or any other deliverables.

\section{Risk Management Plan}

\subsection{Identification and Analysis}

There are many different types of risks that may affect the development and production of our software product. These are:

\begin{enumerate}
\item \textbf{Technological} This is a very small risk as this would only pose a problem if something tremendously bad was to happen such as the corruption of the University server. This is very unlikely meaning it only poses a very small risk.
Another technological risk would be, mismatching files due to multiple people editing the same document. However this is only a minor risk as we use SVN to stop this from happening.
\item \textbf{People} This is also a fairly small risk as this would only occur if either one of our group members drops out of the team or is in a severe accident. Both of which are very unlikely, however both are still possible meaning that this posses a slight risk to the production of our product.
\item \textbf{Organisational} This is also a very small risk as this would only come into play if for instance the lecturers setting the task suddenly decide they hate each other and refuse to cooperate with each other. Or due to unforeseen budget cuts the school of computing science no longer has enough money to continue this course.
\item \textbf{Requirements} This is also a small risk, as the project develops our clients may change there initial requirement after learning more about the product they actually want.
\item \textbf{Unrealistic schedules}  This may pose a significant risk as this is our first time planning and developing a product together as a team. This means it will be hard for us to properly judge an appropriate time scale for the development of this product, which may pose a problem in the future.
\item \textbf{Real time performance shortfalls} This may be another significant problem as there could be a incorrect estimation in the amount of time anyone in the project team believes he or she could complete a specific task. This would lead to a delay in the development process of our product.
\end{enumerate}

Each of the risks above will be analysed, so that the probability of any them occurring can be determined:

\begin{enumerate}
\item \textbf{Technological} This risk would be catastrophic, but has a very low probability.
This risk would be a tolerable risk, and it has a low probability.
\item \textbf{People} This risk would be serious, but has a low probability.
\item \textbf{Organisational} This risk would be catastrophic, but has a very low probability.
\item \textbf{Requirements} This risk would have a tolerable effect, and has a moderate probability.
\item \textbf{Unrealistic schedules} This risk would have a tolerable effect, and has a high probability.
\item \textbf{Real time performance shortfalls} This risk would have a tolerable effect, and has a high probability.
\end{enumerate}

\begin{table}[h]
\begin{center}
\begin{tabular}{| c | c | c | c |}
\hline
\textbf{Risk} & \textbf{Risk type} & \textbf{Probability} & \textbf{Effects} \\ \hline
Technical fault with University systems & Technology & Very low & Catastrophic \\ \hline
Project is cancelled or restructured & Organisational & Very low & Catastrophic \\ \hline
Group member leaves/does not contribute & People & Low & Serious \\ \hline
Clients modify requirements & Requirements & Moderate & Tolerable \\ \hline
Schedules are unrealistic & Estimation & High & Tolerable \\ \hline
Time to develop software is underestimated & Estimation & High & Tolerable \\ \hline
\end{tabular}
\caption{Summary of risk identification and analysis}
\end{center}
\end{table}

\subsection{Monitoring}

Risk monitoring will be carried out on a regular basis, to ensure that each of the risks identified above shall be kept under check. As the project progresses this document shall be redrafted many times and the risks shall be readdressed so to ensure any possible risk triggers and monitored. This means that we shall be aware to any possible events that may affect the production of the product, meaning we will be able to plan in advance to minimise the effects of this incident.

\subsection{Avoidance}

We shall implement risk avoidance by planning for the risks and using the risk avoidance and minimisation techniques outlined in the course textbook. For example:

\begin{enumerate}
\item \textbf{Technological} This risk could be minimised by alerting the clients to our current situation and explaining why delays may occur. This may also be minimised due to the multiple access points that are open to us for accessing our data, due to it being stored in multiple locations.
\item \textbf{People}  This risk could be avoided by planning to have some extra time in the production process, meaning that if there where to be any problem, then we would have time to deal with them.
\item \textbf{Organisational} This risk could be avoided by ensuring that the organisation is aware of the importance of the project, and the negative effects associated with its cancellation.
\item \textbf{Requirements}  This risk could be minimised by making sure that our clients are well informed about the type of product they want to produce, so that they will not change their requirement during the projects progression.
\item \textbf{Unrealistic schedules}  This risk could be minimised by looking at other projects similar to our and the time scales that where set for them. This would mean we would have a better idea as to what a realistic time scale is, so that we could set our accordingly.
\item \textbf{Real time performance shortfalls} This risk could be minimised, by testing our own capabilities before we set a time to perform a task so that. The time set for it will be enough for each of us to complete it.
\end{enumerate}
\newpage
\subsection{Mitigation}

In the event of the risks above coming to fruition, we will employ the following strategies to attempt to minimise the disruption to the project:

\begin{table}[h!]
\begin{center}
\begin{tabular}{| p{5cm} | p{10cm} |}
\hline
\textbf{Risk} & \textbf{Mitigation/minimisation strategy} \\ \hline
Technical fault with University systems & The University operates a nightly back-up system for data stored on the PSD3 team filestore. In addition to this, documents will be stored on our own machines and backed up to the internet. This ensures that the files are stored in three places. \\ \hline
Project is cancelled or restructured & Our team is organised in such a way that will allow us to be flexible in response to organisational changes. Beyond that, we will ensure that the impact of such changes is highlighted. \\ \hline
Group member leaves/does not contribute & The team will be organised in such a way that more than one person has an understanding of each task. This will allow another person to take over the task should the need arise. \\ \hline
Clients modify requirements & Our client interviews and requirements gathering process will ensure that we have a comprehensive and firm view of the clients requirements. Should these change, we will outline the implications of such changes to the client. \\ \hline
Schedules are unrealistic & Our schedules have been developed to allow slack time, which allows us some scope to overrun on a given task. As the project proceeds, we will revise our schedules. \\ \hline
Time to develop software is underestimated & As above, slack time has been built in to our schedules, and development time will be revised as necessary. \\ \hline
\end{tabular}
\caption{Risk mitigation/minimisation strategies}
\end{center}
\end{table}
\subsection{Review}

While we have identified a number of risks to our project, the majority of these are tolerable, or are catastrophic but with a very low probability of occurring. This does not indicate that we should be complacent, and we will ensure that as the project proceeds, we implement our strategies to both monitor and mitigate the risks that we have outlined.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\section{Configuration Management Plan}

\subsection{Version Management}

In order to track of revision history for our files, we have decided to use Subversion (SVN).
This will allow us to individually track changes to each component in the project, attaching an incremental revision number to each, which is in the form of \em{r245} for revision number 245 as an example. 
We can then, at any point, revert back to a previous version of a specific component if necessary using this revision number.
Additionally, SVN provides an easy way to create branches in the project, thus once we have identified a baseline set of components, we can create a new branch containing only these baseline components, which would then be kept separately from the rest of the project.
These baseline branches can then be numbered incrementally in the form of \em{v1, v2, v3, etc}.

\subsection{Change Management}

To ensure there no issues arise due to changes in the requirements, we have implemented the following system:

If a required change has been identified due to some new information from a stakeholder, a group discussion would be called. 
This discussion would involve identifying which components the change would effect, the effort the change would require and the worthiness of the change. 
If the change is accepted, a new task would be created in our Trac system which would then allow us to assign this task to a specific team member with the appropriate information. 
Project documentation would then also have to be updated in order to reflect this change, even in cases where the case was rejected so that the rationale for the rejection can be explained.

\subsection{Baseline Identification}

As we already have a fixed set of milestones which match up with the required project deliverables, these can be considered the points at which baseline identification will occur. 
Baseline identification will be, again, done as a group exercise and will involve looking at each component and comparing it against the projects requirements. 
If the group agrees that the component has truly reached that milestone, that component will be then become a baseline component using the process described in the section above. 

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\newpage

\appendix

\section{List of tables and figures}

\listoftables

\listoffigures

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\end{document}

